Modern corporate wide area networks (WANs) often take the form of internet protocol-based virtual private networks (IP-VPNs) which make use of multi protocol label switching (MPLS). IP-VPNs are flexible and allow corporate users to share network infrastructure while giving the appearance of private network use. Typically the shared network infrastructure is provided by a particular network service provider, although it can be provided by the public internet.
MPLS IP-VPNs are designed and delivered to meet specific traffic volumes at anticipated qualities, of service (QoS). The bandwidth and other QoS requirements are typically translated into appropriate router settings for each corporate site accessing the IP-VPN, using for example DiffServ (Differentiated Services, a model defined by the Internet Engineering Task Force) to define class of service (CoS) ratios which categorise traffic into different Assured Forwarding (AF) classes.
The router settings are usually applied through the network service provider provisioning workflow and provisioning Operational Support System (OSS) infrastructure. As a result, any change to service is typically handled as a change control, engaging the full OSS stack, and can take typically from a few hours to a few days, weeks or even months to implement, depending on how many sites are involved and the complexity of the changes required.
However, there is a growing need for service providers to provide applications on-demand (for example video broadcasting and video conferencing through an IP-VPN). Furthermore, the introduction of a wide range of eBusiness services is beginning to place unpredictable and “bursty” demands on corporate networks.
Moreover many transactions which may appear as a simple mouse-click to the end user are in fact highly complex in terms of network usage. A simple example is the load of a web page, which may result in multiple application flows to different servers to produce the constituent text and graphics, perhaps one for order catalogue information, one for stock availability, and one for company information, each flow being across a different network path to a different server.
In order to guarantee the performance of such applications and thus enable businesses to run effectively, it would be desirable for the network to adapt in real time to knowledge of the application and the overall transaction, against pre-defined targets associated with what constitutes a good user experience for the application. Furthermore, if the network fails to adapt within the current provisioning, it would be advantageous if action were automatically taken to re-provision based on policies agreed with the end-client and the service provider as part of the Service Level Guarantee (SLG). Furthermore if an SLG cannot be met by any means, it would be advantageous if the network were able to deliver punitive compensation automatically. Clearly this is not possible with the “typical” OSS stack previously summarised.